Content Adaptation

ABSTRACT

A system includes a mobile device and an optimization server. The mobile device is capable of transmitting request data that includes a requested webpage and identification data. The optimization server is configured to receive response data that corresponds to the request data from a content server, to adapt the response data based on the identification data, and to transmit the adapted response data to the mobile device.

RELATED APPLICATIONS

This application is a divisional of U.S. application Ser. No.11/636,033, filed Dec. 8, 2006, titled “Content Adaptation,” which isincorporated herein by reference.

BACKGROUND INFORMATION

The Internet allows for vast amounts of information to be communicatedover any number of interconnected networks, computers, and networkdevices. Typically, information or content is located at websites on oneor more content servers, and a user can retrieve this content using auser agent, such as a web browser, running on a client device. Forexample, the user can input a webpage address into the web browser oraccess a web link, which sends requests to the server to access andprovide to the user the content on the respective website. This type ofcommunication is commonly referred to as “web browsing.”

Web browsing is enjoyed by millions of users on the Internet. Becauseweb browsing has become so widespread, many websites provide morecomplicated, enhanced visual effects and features. These enhancedqualities are generally directed towards a user viewing the website froma typical computer, such as a laptop, PC, etc.

Mobile web browsing has gained some traction because of the increasednetwork speed, improved browsers, more powerful devices, and betterpricing plans. But significant challenges still remain for Internetbrowsing on a mobile phone to become more popular among users. Some enduser challenges include the frustration over long download times, thelack of accessibility, the lack of performance, and the lack ofusability. For example, it may take over a minute for a full download ofwww.msn.com from a mobile phone on a typical network without multipartencoding. Accessibility challenges include the inability of WAP 2.0browsers to render rich HTML content; the lack of plug in support forrich multi-media content; and the lack of support for DHTML websites.Performance challenges include the large latency in wireless networks,the discrepancies between uplink and downlink bandwidth, and TCPlimitations. Along with the accessibility and performance issues,usability challenges can include, among other things, attempting to fita large complicated page onto a small screen. In addition to thesechallenges to the user, website developers also face challenges such asthe lack of standards for defining the device and the browserscapability, and the large test matrix of a myriad device and browsercombinations. For mobile web browsing to become more readily operablefor the user, these issues must be addressed.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of an exemplary system.

FIG. 2 is a block diagram illustrating an embodiment of the exemplarysystem of FIG. 1.

FIG. 3 is a functional diagram illustrating an exemplary communicationflow for the exemplary system of FIG. 2.

FIGS. 4A & 4B illustrate a Document Object Model tree structure and acorresponding webpage.

FIG. 5 is a flowchart representing the steps of an exemplary method forprocessing request data.

FIG. 6 is a flowchart representing the steps of an exemplary method forprocessing response data.

FIG. 7 is a flowchart representing the steps of an exemplary method forprocessing JavaScript coding.

FIG. 8 is a flowchart representing the steps of an exemplary method forproviding content styling.

FIG. 9 is a flowchart representing the steps of an exemplary method forperforming small screen adaptation of the original web page andpaginating the response data.

FIG. 10 is a flowchart representing the steps of an exemplary method forperforming form processing.

FIGS. 11A & 11B are block diagrams illustrating the exemplary effects ofform processing.

DESCRIPTION OF THE EMBODIMENTS

Reference will now be made in detail to the exemplary embodimentsimplemented according to the invention, the examples of which areillustrated in the accompanying drawings. Wherever possible, the samereference numbers will be used throughout the drawings to refer to thesame or like parts.

FIG. 1 is a block diagram of an exemplary system. Exemplary system 100can be any type of system that transmits data over a network, such as awireless network, Internet, etc. For example, the exemplary system caninclude a browser requesting access to content from content serversthrough the Internet. The exemplary system can include, among otherthings, a user agent 102, a client device 104, a gateway 106, one ormore networks 108, 112, an optimization server 110, a storage device114, and one or more content servers 116-118.

User agent 102 is a client application used with a network protocol. Forexample, user agent 102 could be a web browser, a search engine crawler,a screen reader, or a Braille browser, and user agent 102 could be usedto access the Internet. User agent 102 can be a software program thattransmits request data (e.g., an HTTP/HTTPS/WAP/WAIS/Gopher/RTSPrequest, etc.) to a web server and receives response data in response tothe request data. For example, user agent 102 can send request data tocontent servers 116-118 for a particular file or object data of a webpage by its URL, and the content server of the web page can query theobject data in a database and can send back the object data as part ofthe response data (e.g., HTTP/WAP response data) to the user agent. Thisprocess continues until every object in the web page has been downloadedto the user agent.

Client device 104 is a computer program or hardware device that canaccess remote services. Client device 104 can receive request data fromuser agent 102, can transmit the request data to the content servers,and can receive response data in response to the request data. Forexample, client device 104 can be Bytemobile Optimization ClientSoftware. In some embodiments, user agent 102 and client device 104 canbe housed in the same device, such as a computer, a PDA, a cell phone, alaptop, or any device accessing the Internet. In some embodiments,client device 104 can be removed and its functionality can be includedin user agent 102.

Gateway 106 is a device that converts formatted data provided in onetype of network to a particular format required for another type ofnetwork. Gateway 106, for example, may be a server, a router, a firewallserver, a host, or a proxy server. The gateway 106 has the ability totransform the signals received from client device 104 into signals thatnetwork 108 can understand and vice versa. Gateway 106 may be capable ofprocessing audio, video, and T.120 transmissions alone or in anycombination, and is capable of full duplex media translations.

Networks 108 and 112 can include any combination of wide area networks(WANs), local area networks (LANs), or wireless networks suitable fornetworking communication such as Internet communication.

Optimization server (OS) 110 is a server that provides communicationbetween gateway 106 and content servers 116-118. For example, OS 110could be a Bytemobile Optimization Services Node. OS 110 can optimizeperformance by enabling significantly faster and more reliable serviceto customers. OS 110 can include optimization techniques, which arefurther described below.

Storage device 114 is a device that stores adaptation parametersrelating to the specifications of user agent 102 and a device utilizingthe user agent 102. In some embodiments, storage device 114 can beincluded with OS 110, local to OS 110, or remote from OS 110. The storedadaptation parameters can assist OS 1.10 in determining what kind ofoptimization techniques are provided to user agent 102 and the device.Storage device 114 can be any type of device that stores data.

Content servers 116-118 are servers that receive the request data fromuser agent 102, process the request data accordingly, and return theresponse data back to user agent 102. For example, content servers116-118 can be a web server, an enterprise server, or any other type ofserver. Content servers 116-118 can be a computer or a computer programresponsible for accepting HTTP requests from the user agent and servingthe user agents with web pages.

FIG. 2 is a block diagram illustrating an embodiment of the exemplarysystem of FIG. 1. Mobile device 202 is a wireless device that caninclude, among other things, user agent 102 and/or client device 104. OS110 may include, among other things, a request monitor 210, a contentcache 220, a response monitor 230, an adaptor 240, and interfaces 250,260. As stated above, in some embodiments, storage device 114 can belocated within, local to, or remote from OS 110.

Request monitor 210 can be a software program or a hardware device thatreceives or intercepts the request data, such as an HTTP request for aspecific URL, from mobile device 202. Request monitor 210 has theability to extract identification data, from the request data and toprovide the identification data to the storage device 114 in exchangefor adaptation parameters, which can be provided to adaptor 240 forfuture processing. Identification data can include, among other things,the type of user agent and the type mobile device, and the adaptationparameters can include data describing the properties of the user agentand mobile device, such as screen size, etc. Request monitor 210 canalso communicate with the content cache 220 to provide stored adaptedresponse data (e.g., sub-pages) to the mobile device 202. Further,request monitor 210 can transmit the request data to content server 116if the request data does not request the adapted response data.

Response monitor 230 can be a software program or a hardware device thatreceives response data from content server 116. After receiving theresponse data, response monitor 230 provides the content data to adaptor240, which adapts the response data for mobile device 202. Dependingupon whether the response data is to be adapted for the mobile device,response monitor 230 can provide either the response data or the adaptedresponse data to mobile device 202.

Adaptor 240 can be a software program or a hardware device that receivesthe response data from response monitor 230 and adapts the response datain accordance with the adaptation parameters received from requestmonitor 210. This adaptation process will be further described below.Adaptor 240 can provide the adapted response data to response monitor230 and/or content cache 220. In some embodiments, the adapted responsedata includes a main adapted sub-page and subsequent adapted sub-pages.The main adapted sub-page could be provided to the response monitor 230,which provides it to mobile device 202 for downloading and displaying.These sub-pages could be stored at content cache 220 for futurereferencing.

Content cache 220 is a device that stores adapted response data (e.g.,adapted sub-pages) for future referencing. Content cache 220 can providethis adapted response data to request monitor 210, which can provide theadapted response data to mobile device 202 without having to re-requestresponse data from content server 116. Content cache 220 can alsoprovide adapted response data to response monitor 230, which transmitsthis data to mobile device 202. In some embodiments, content cache 220can directly provide the adapted response data to mobile device 202.

Interfaces 250 and 260 are software programs or hardware devices thatcommunicatively couple OS 110 with mobile device 202 and content server116 through wired or wireless communication means. Each interface hasthe ability to communicate with the elements of OS 110, translate thecommunication so that the communication means can utilize the data, andtransmit the translated communication across the correspondingcommunication means. In some embodiments, interfaces 250 and 260 caninclude encryption means and/or decryption means to encryptcommunications leaving from and decrypt communications coming into OS110.

FIG. 3 is a functional diagram illustrating an exemplary communicationflow in the exemplary system of FIG. 2. It is assumed for the purposesof explaining this exemplary communication flow that the request datacorresponds to a request for a URL and that content cache 220 has notstored any adapted response data corresponding to the requested URL.Further, while the exemplary communication flow illustrates OS 110providing the content adaptation, in some embodiments, the user agentmay include additional components to locally assist the contentadaptation process by transferring or further translating the adaptedinformation.

The user inputs a URL into a user agent of the mobile device 202. Mobiledevice 202 then transmits (302) the request data to OS 110. The requestdata can include, among other things, the requested URL andidentification data identifying the mobile device and the type of useragent on the mobile device. The request data can be directed explicitlyto a gateway or proxy and then to OS 110, or it can be directed tocontent server 116 and the request can be intercepted transparently byan inline proxy or gateway.

Request monitor 210 extracts the identification data from the requestdata and then transmits (304) the identification data to storage device114. Responsive to the identification data, storage device 114 returns(306) adaptation parameters to request monitor 210. In some embodiments,the adaptation parameters may include, among other things, the followingdata:

Adaptation parameters Meaning/Use JavaScript support whether the devicesupports JavaScript Screen width usable screen width in pixels Screenheight usable screen height in pixels Markup language usually XHTML orXHTML/MP Color depth bit-depth used for image transcoding/byte-reductionMaximum bytes per page devices generally have problems when the pagesize exceeds this limit Maximum images per page some devices haveproblems when the number of images exceeds this limit Maximum links perpage few devices have problems when the number of links exceeds thislimit Font-size support whether variable font-sizes can be usedFont-family support whether variable font-families can be used Preferredfont-family default font-family of the device Minimum font size thesmallest size where differences in font size are no longer renderedMaximum font size the largest size where differences in font size are nolonger rendered Number of available font how many different font sizescan be specified between sizes min and max where each font size isrendered differently HTML table support whether the browser can rendertables Previous sub-page soft-key The key number in the handset keypadto link to the “Previous sub-page” action Next sub-page soft-key The keynumber in the handset keypad to link to the “Next sub-page” action Topof page soft-key The key number in the handset keypad to link to the“Top of the page” action Bottom of page soft-key The key number in thehandset keypad to link to the “bottom of page” action Referring pagesoft-key The key number in the handset keypad to link to the “Previouslyviewed site” action Maximum URL length Some devices cannot handle longURLs Maximum HTML title length Used to chop title for browser whichdon't manage long titles properly User Agent Used for device-specificadaptations

Upon receiving the adaptation parameters, request monitor 210 canforward (308) the adaptation parameters to adaptor 240 for futurereferencing. In some embodiments, adaptor 240 receives theidentification data from request monitor 210, stores it, and exchangesthe identification data for the adaptation parameters located in storagedevice 114.

After communicating with adaptor 240, request monitor 210 forwards (310)the request data to content server 116. Subsequently, content server 116provides (312) response data (e.g., HTTP response), associated with therequest data, to response monitor 230 of OS 110. The response data caninclude, among other things, an HTML document, a Cascaded Style SheetFiles, and one or more JavaScript files, all of which constitute therequested webpage. These web pages include a collection of nested HTMLelements, represented by tags. The OS 110 can utilize a parser to createa data structure that stores the tags found in the HTML document foraccessing and manipulating each individual element in the HTML document.Because HTML tags can be nested, this data structure is likely to be inthe form of a tree.

The Document Object Model (DOM) interface is a standard method to accessthis tree-like data structure, commonly referred to as the DOM tree ofthe HTML document, and represents the requested web page. Theembodiments described herein generally assume a DOM tree as the input,but it would be readily appreciated by one of ordinary skill in the artthat any other type of data structure representing a web page can beused. Further, it would be readily appreciated by one of ordinary skillin the art that any other method for accessing and traversing theelements in the webpage can be used.

The following sample HTML document illustrates some key concepts:

<html> <head> <title> The Document Title </title> </head> <body> <div><h1> A section header </h1> <p> a paragraph</p> </div> <span> <p>Another Paragraph </p> </span> </body>. </html>For example, FIG. 4A illustrates a very simplified DOM tree structurethat represents the sample HTML document. In this DOM tree structure,node 400 is the root node and is also the parent node of child nodes402, 414. An exemplary embodiment could be that root node 400 has an<HTML> tag, which identifies root node 400 as being written in HTML.Further, node 402 includes a <Body> tag and node 414 includes a <Head>tag. The <Body> tag encloses the actual, visible content of the HTMLdocument, and can be used to define style properties that apply to theentire document, such as the background image, the text, the link, andthe visited link colors. The <Head> tag encloses special tags bearinginformation about the document itself. Node 414 has a child node 416, adescendent of both node 400 and node 414. For this particular example,node 416 includes a <Title> tag, which identifies the node having thetitle of the page at the head of the document. Node 402 links to nodes404, 410, which are both descendents of node 402 and 400. In thisexample, node 404 is a <div> tag that encloses a header <h1> tag (node406) and a paragraph <p> tag (node 408) while node 410 is a <span> tagused to apply style to the “another paragraph”<p> tag in node 412.Ultimately, each node in the DOM tree may be displayed, or rendered fora computer screen by using the style information provided in thewebpage's CSS files. As a result of the rendering process, each node inthe DOM tree can have geometric and style properties. For example, therendering process of the data tree structure provided in FIG. 4A couldproduce the exemplary webpage provided in FIG. 4B. FIG. 4B provides thecorresponding reference numbers that relate to the data tree structureprovided in FIG. 4A and the sample HTML document provided above.

Referring back to FIG. 3, if adaptation is required, response monitor230 provides (314) the response data to adaptor 240, which adapts theresponse data for mobile device 202 based on the adaptation parametersprovided in step 308. Adaptor 240 traverses the DOM tree structure, tocreate adapted request data that would maintain the look and feel of theoriginally requested webpage. This adaptation can also include contentstyling, JavaScript processing, small screen adaptation, and paginatingthe response data, wherein paginating includes, among other things,separating the request data into several sub-pages because the screenand/or user agent on the mobile device may not be able to accommodatethe entire webpage. For example, if a user requests cnn.com, the entirecnn.com webpage could not be displayed on the phone because the downloadwould take too long and/or the mobile device's memory could not besufficient to accommodate all of the information. Paginating would allowcnn.com to be broken up into several sub-pages while still maintainingthe look and feel of the original page.

If the adaptor creates several sub-pages, the adaptor can determine theadapted main sub-page and the subsequent sub-pages. For example,referring back to the cnn.com example, the breaking news section ofcnn.com could be the adapted main sub-page while the latest news tabbox, the menu items, etc. could all be in the same or differentsub-pages. As will be explained later, the sub-pages can include headerand footer data that link to prior and subsequent sub-pages.

By creating these sub-pages, adaptor 240 assists mobile device 202because mobile device 202 does not have to download the entire webpage.If the adapted response data includes one or more subsequent sub-pages,adaptor 240 can forward (316) these one or more subsequent sub-pages tocontent cache 220 to be stored for future referencing. If the sub-pageis the adapted main sub-page, adaptor can forward (318) the adapted mainsub-page to response monitor 230, which forwards (320) the adapted mainsub-page to mobile device 202 for downloading and displaying. In someembodiments, adaptor 240 can forward the adapted main sub-page toresponse monitor 230 at step 318 prior to forwarding the subsequentsub-pages to content cache 220 at step 316. Further, in someembodiments, adaptor 240 can bypass forwarding the adapted main sub-pageto response monitor 230 and can directly forward it to the mobile device202 itself.

The user can then view the adapted main sub-page at mobile device 202.If preferring to view a subsequent sub-page, a user can request thissub-page by linking to it through a footer on the bottom of thedownloaded main sub-page. Then, mobile device transmits (322) therequest data, which includes the request for the subsequent sub-page, toOS 110.

Request monitor 210 receives the request data and analyzes it todetermine whether the request data includes a request for new contentdata or for another subsequent sub-page. In this particular case,request monitor 210 determines that the request is for another sub-page.Because of this determination, request monitor 210 communicates (324)the request to content cache 220 for the requested adapted sub-page.Upon receiving the adapted sub-page, request monitor 210 can forward(326) it to mobile device 202 for downloading. In some embodiments, oneof ordinary skill in the art would appreciate that content cache 220 canforward the cached adapted sub-page directly to mobile device 202.

FIG. 5 is a flowchart representing an exemplary method for processingrequest data. It will be readily appreciated by one of ordinary skill inthe art that the illustrated procedure can be altered to delete steps orfurther include additional steps. After initial start step 500, an OSreceives (502) request data from a mobile device.

After receiving the request data from mobile device, the OS determines(504) whether the request is for an adapted sub-page. If so, the OScommunicates (514) the request data to the content cache for theparticular adapted sub-page corresponding to the request data and thenforwards (516) the particular sub-page to the mobile device fordownloading and displaying. After the forwarding, the method can proceedto connector 518 and then end (520).

On the other hand, if the request data does not correspond to a requestfor an adapted sub-page, the request data corresponds to a request forcontent data (e.g., HTTP content) resulting in the OS extracting (506)identification data from the request data. The identification dataprovides a sequence of alphanumeric symbols that include data about themobile device type and the user agent type. The OS communicates (508)the identification device to a storage device in exchange for adaptationparameters (e.g., the adaptation parameters provided in the chartabove), which assist the OS in determining how to adapt the content datafor the requesting mobile device. Upon receiving the adaptationparameters, the OS can provide (510) the adaptation parameters to theadaptor for future processing.

The OS can then transmit (512) the request data to a content serverwhere the content server transmits response data to the OS; the responsedata including content data corresponding to the request. In someembodiments, the OS can add additional parameters to the request data toensure that the content server will reply with a webpage. In someembodiments, transmission step 512 can be located between extractionstep 506 and communication step 508. After the transmission, the methodcan proceed to connector 518 and then end (520).

FIG. 6 is a flowchart representing an exemplary method for processingresponse data. It will be readily appreciated by one of ordinary skillin the art that the illustrated procedure can be altered to delete stepsor further include additional steps. After initial start step 600, an OSreceives (602) response data from a content server.

After receiving the response data, the OS determines (604) whether theresponse data is to be adapted for the mobile device. For example, somewebsites, such as Google, are mobile-aware, and provide a responsealready adjusted specifically for mobile devices and hence, may not needthe adaptation process. In some embodiments, mobile-aware response datamay still require adapting by the OS. If the request data is not to beadapted, the OS can transmit (608) the non-adapted response data to themobile device for downloading. After the transmission, the method canproceed to connector 622 and then end (624).

On the other hand, if the response data is to be adapted for the mobiledevice, the OS parses and traverses (610) an original DOM tree structureof the response data (e.g. HTTP response data). As a result of theparsing, the OS can provide a DOM tree that can be traversed to performat least one of the following for adaptation: JavaScript processing(612), content styling (614), and paginating and small screentransforming (616), which will be further described in FIGS. 7, 8, & 9,respectively. These adaptation processes can work together or operate asa single standalone process. These adaptation processes can alter awebpage provided by the response data to be broken down into severalsub-pages, which can include a first adapted main page and/or one ormore subsequent adapted sub-pages. The OS caches (618) these one or moreadapted sub-pages for future referencing and provides (620) the adaptedmain adapted page to the mobile device for downloading. If the user atthe mobile device requests one of these adapted sub-pages, the OS canprovide them to the mobile device without having to re-request the datafrom the content server. In some embodiments, where only one mainadapted page was created from the original web-page, the method canbypass storage step 618. After the providing step, the method proceedsto connector 622 and then ends (624).

FIG. 7 is a flowchart representing an exemplary method for processingJavaScript coding. This particular example is concerned with sendingJavaScript code and its relevant execution context state information inthe adapted sub-page(s) to retain key JavaScript functionality in theadapted sub-page to be provided to the mobile device. This exemplarymethod effectively provides a “snapshot” and transfers the executioncontext to the mobile device browser. In this example, JavaScriptfunctionality considered critical relates to the animation andprocessing of HTML forms and tab boxes. This exemplary method can beextended to preserve other types of functionality. It will be readilyappreciated by one of ordinary skill in the art that the illustratedprocedure can be altered to delete steps or further include additionalsteps or functionality. It is assumed for purposes of this method thatupon receiving the response data, an OS creates a JavaScript Engine toprepare the JavaScript Execution Context according to StandardJavaScript Specifications, summarized herein at steps 702 to 708.

After initial start step 700, the OS extracts (702) all JavaScript codeand references from the original DOM tree structure and any relatedJavaScript files to build the JavaScript Execution Context (JSContext).The JSContext provides a list of all JavaScript objects defined in theglobal scope of the requested web page. This list includes objects ofuser-defined type, objects of built-in type (data, string, etc.), nativeobjects exposed to JavaScript (document, window, etc.), and specialobjects, such as functions. Then, a JSProcessor extracts (704) the listof JavaScript objects from the JSContext and stores (706) them as keysin a global object map. In some embodiments, native objects are notincluded in the global object map because these objects can be providedby the user agent's JavaScript implementation. Once the web page isfully loaded and the JS execution context (JSContext) is built, theJSProcessor executes (708) all “onload” JavaScript functions. OnloadJavaScript functions perform additional downloads, initialization, andformatting of the webpage. After onload script execution, the web pagereaches a static state and usually waits for user interaction.

Then, the OS can begin traversing the DOM tree structure by traversing(712) the next non-traversed node (e.g., first designated node). Duringthe DOM tree traversal, the OS examines each DOM node, which representsan HTML element, to determine whether it references JavaScript objects,and if so, whether those JavaScript objects will be needed in theadapted page to retain desired functionality. The OS determines (714)whether the current HTML element node in the DOM tree structure beingvisited references JavaScript in one or more of its attributes. Forexample, a node meeting this first condition can include an anchor tag,with an <href> attribute, containing a JavaScript function call and aselect tag with an onchange attribute containing actual JavaScript. Ifthe attributes do not reference JavaScript, the method proceeds toconnector 734 and the method further, if needed, traverses the next nodewithin the DOM tree structure.

On the other hand, if the attributes refer to JavaScript, the OSdetermines (716) whether the JavaScript object(s), referenced by thisHTML element node, are necessary (and can be executed) in the resultingadapted sub-page to retain the desired functionality. This determinationinvolves the OS determining whether at least one of the following can besatisfied: this DOM node is located in a DOM sub-tree marked for directcopy (e.g., as a result of a tab box preservation technique furtherdescribed below); this DOM node is a descendant of a form node; this DOMnode is form-related even though it may not be inside a form (select,input, etc.); and this DOM node includes any other criteria relatedbeyond tab-box and form processing (if used as an extension of thisexemplary method). If none of these conditions are met, the methodproceeds to connector 734 and the method, if needed, further traversesthe DOM tree structure. Otherwise, if at least one of these conditionsis met, then the JavaScript object(s) should be provided in the adaptedpage, and this object, as well as all the objects referenced during itsexecution, should be extracted from the global map and sent in theadapted page.

For this purpose, the OS can build an object dependency graph, whichidentifies the relationship of the current object to other objects inthe global map, during the DOM tree traversal. Steps 718 to 732 refer tobuilding this dependency graph and extracting the JavaScript code to beincluded in the adapted sub-page(s). These steps are exemplary and mayvary in different embodiments to achieve the objective of retrievingJavaScript code required to continue the execution in the adapted page.The dependency graph in this case is implemented as a set (a type ofdata structure). In addition, the “class” and “id” attributes (if any)of this HTML element are retained in the adapted page.

Next, the OS parses the JavaScript found in the attribute value for anyreference to objects in the global map. To begin the parsing, the OStokenizes (718) the JavaScript code (e.g., by using the JavaScriptEngine's lexical scanner) into a list of identifiers. After thetokenization, the OS extracts (722) the identifiers matching theJavaScript object in the global object map. The identifiers that match aglobal object name are added (724) to the current DOM node's dependencyset, which stores global object names that this JavaScript depends upon.The OS decompiles (726) the global object into source code, whichprovides a snapshot of the global object at this instant in time. The OSthen stores (728) this source code in the global object map at an entrycorresponding to the global object's name. Next, the OS tokenizes (730)this source code to determine if it references other global objects bylooking up the identifier tokens in the global object map.

After tokenizing this new fragment of source code, the OS determines(732) whether the source code references other global objects by lookingup identifiers in the global object map. If so, the process is iteratedby proceeding to connector 720 until no more dependencies are found.After decompiling and tokenizing a global object, any dependencies foundduring the recursive dependency search are cached in the object'sdependence set. If an object, whose dependencies were already processed,is queried again during a subsequent recursive dependency search, acached dependence set is used, avoiding the re-processing. The followingexample illustrates dependency caching. Suppose there are two HTMLelements in the original document and the objects in the left column aredefined in the global scope of this document as well.

-   -   HTML Element 1: <input onmouseover=‘alert(y)’>    -   HTML Element 2: <select onchange=‘foo( )’>

Dependence Dependence Sets After HTML Set After HTML Global ObjectElement 1 Element 2 var x = 5 var y = x + 10 X x (cache hit) bar( ) {alert(y − 2) } x, y foo( ) { bar( ) } bar, x, y

Notice that the ‘alert’ identifier would be after decompiling andtokenizing ‘bar.’ The ‘alert’ function (object) is provided by thenative implementation. Thus, in some embodiments, this non-native objectis not included in the dependency sets because it is assumed that thetarget device will provide this object.

This example also illustrates the concept of taking a snapshot of theexecution context. For example, variable X holds the value 5. Tocontinue the execution in the target device, the current value of x willbe needed for the JavaScript application to work properly. Thede-compilation step at step 726 can provide JavaScript code that wouldset the variable to the value it had at snapshot time. If determinationstep 732 determines that the source code refers to other global objectson the map, the method proceeds to connector 720 for furtherdecompiling, storing, and tokenizing the remaining objects.

On the other hand, if the source code does not refer to other objects inthe global object map, the OS determines (736) whether all DOM nodeshave been traversed in the original DOM tree structure. If not, themethod proceeds with the traversal of the original DOM tree by advancingto connector 708 and the next DOM node is traversed.

On the other hand, if the traversal has reached the root node, the OSconstructs (738) JavaScript source code. This construction can occurduring a serialization function (provided in FIG. 9) used for preparingthe final HTML code to be sent, managing the dependency sets for eachHTML element in the DOM tree structure and merging them (eliminatingduplicates between DOM sub-trees) as the DOM tree representing asub-page is traversed bottom-up. Serialization is performed in severalbottom-up traversals (one for each identified Content Section), and oncethese traversals reach the root node, the merged dependency graphrepresents all global objects on which the entire DOM tree is dependent.Constructing the adapted source code involves querying each name in themerged dependency set provided in the root DOM node of each contentsection. The source code for each object (which has already been storedfor these objects) is returned and appended to the sub-page beingprepared for output to mobile device for all the content sectionsincluded in the sub-page (the appending is provided in FIG. 9 at step916). The resulting source code for all required objects can compileinto a state identical to the state of the original document afteronload scripts have been executed—without any of the original onloadscripts present in the resulting document—resulting in a transfer of theexecution context to the mobile device. After constructing the finalJavaScript code, the method can end 740.

FIG. 8 is a flowchart representing an exemplary method for contentstyling. It will be readily appreciated by one of ordinary skill in theart that the illustrated procedure can be altered to delete steps orfurther include additional steps. Providing this content styling processto the resulting small-screen adapted content structures helps an OSsignificantly reduce the bytes of Cascading Style Sheet (CSS)information while preserving the original look and feel of the originalwebpage. Of the numerous CSS properties that can be applied to an HTMLtag of the DOM tree structure, this method defines a subset of essentialstyle properties affecting the rendering and displaying of HTML elementsto retain the look and feel of the original content in the small-screenadapted content. For example, the essential properties may include,among other things, the following:

-   -   font-style—The font-style property sets the style of a font        (italic, oblique).    -   font-variant—The font-variant property is used to display text        in a small-caps font, which means that all the lower case        letters are converted to uppercase letters, but all the letters        in the small-caps font have a smaller font-size compared to the        rest of the text.    -   font-size—The font-size property sets the size of a font.    -   font-weight—The font-weight property sets how thick or thin        characters in text should be displayed (often used to bold        characters).    -   font-family—The font-family property is a prioritized list of        font family names and/or generic family names for an element.        The browser will use the first value it recognizes.    -   text-decoration—The text-decoration property decorates the text.    -   text-transform—The text-transform property controls the letters        in an element.    -   background-color—The background-color property sets the        background color of an element.    -   color—The color property allows authors to specify the color of        an element.    -   display—The display property sets how/if an element is        displayed.    -   width—The width property sets the width of an element.

The essential properties can be the only properties considered by thestyle application method. But there can be exceptions programmed intothe OS, wherein an exception may include the styling of tab boxes inwhich all CSS properties explicitly set in the original page aretransferred to the adapted page.

By applying these retained properties to the resulting content sectionsof the DOM trees during the serialize stage, a significant portion ofthe original's page style can be achieved. The OS can discard thelayout-specific CSS properties, thereby significantly reducing theamount of data transmitted to and downloaded at the mobile device.

The first stage in the style application process extracts the essentialCSS style properties from each HTML element to be included in theadapted page. Extraction can be performed during the traversal of theoriginal DOM tree, simultaneously with JavaScript processing,flattening, etc. After initial start step 800, to begin the extractionprocess the OS begins extracting (802) the DOM tree structure. Uponreaching a node, the OS extracts (806) the essential computed CSS styleproperties from this node during the traversal of the DOM treestructure, saves the CSS style properties to a style structure, andcopies the structure to this node's children nodes. The OS nextdetermines (808) whether any nodes still need to be extracted. If so,the method proceeds to connector 804 to extract additional nodes;otherwise, the OS begins the second stage of content styling.

The second stage of content styling involves applying the appropriatestyle to each node. This function occurs during a serialization process(further explained below in FIG. 9) that creates actual HTML code foreach content section being serialized. Style application can beperformed differentially by including an HTML code imposing style when achange in style is detected. The method for applying style changes triesto incorporate the inheritance features of HTML CSS, and can be appliedin the following exemplary ways:

-   -   When a change in a background color needs to be applied, the OS        wraps all contiguous DOM nodes sharing the same style within a        <DIV> tag thereby forcing the style change.    -   If background color change is not necessary, the OS uses a        <SPAN> tag that forces the new style properties to wrap        contiguous nodes with the same style.    -   Style is applied directly to each node (without using        inheritance) in the following cases:        -   (1) the tag of the node is a h1-h6 tag;        -   (2) the tag of the node is an <anchor> tag being provided to            an openwave browser because these tags have trouble            inheriting style;        -   (3) the node is a preformatted node resulting from the            layout preservation small screen adaptation process; or        -   (4) the tag of the node is a tag that cannot be directly            wrapped within a <span> or <div> tag (e.g., an <option>            tag).

The second stage is conducted on each of the adapted Content Section DOMtrees, in a bottom-up fashion during serialize step in FIG. 9. In theparticular embodiment explained in FIG. 8, the method assumes that allstored style properties for each node contain absolute style values(i.e. “background-color=blue”, and therefore, in addition to thedifferential style application, the method includes the detection ofstyle changes between a parent node and its children). The method can bemodified to cover other cases as well. To begin the second stage, the OSselects (812) a parent node and sets the parent node's style as thevariable CurrentStyle. After setting the variable, the OS determines(816) whether the parent node has any children nodes to traverse.

If the parent node has children nodes to traverse, the OS furtherdetermines (818) whether a difference exists between the CurrentStyleand the child node's style. For determining the difference, the OSspecifies the style content by defining classes. One class is definedfor each style property:value pair that is found necessary to be appliedat some point to force a desired style change. Classes are created ondemand during the serialization process as changes in style are found,and are used in enclosure tags (<div> or <span> tags) for inheritance,or applied directly as discussed above. If a difference does not exist,the OS adds (820) the child node to the list of children node that sharethe same style and the method proceeds through connectors 826826 and 814to determination step 816.

On the other hand, if a difference exists, OS wraps (822) the previouschildren nodes in an enclosure tag, sets the current child node style toCurrentStyle, and adds the current child node to a new list of childrennodes. For example, the enclosure tag can be a <div> tag or a <span>tag. Then, the OS associates (824) the CurrentStyle with either a new oran existing style class. If the CurrentStyle is a new style, the OScould create a style class name; add that style value to a global indexand future nodes having the same or similar styles could be added tothis class name; and apply the class name to the enclosure tag.Otherwise, if this nodes style value is the same as or similar to anexisting style value, this node could be added to the pre-existing classname associated with the existing style value.

If the parent node does not have any remaining children to traverse indetermination step 816, the OS further determines (828) whetheradditional nodes remain to be enclosed or wrapped. If so, the methodproceeds to connector 810 and then selection step 812; otherwise, the OSincludes (830) the style values in a paginated sub-page that correspondsto the applied class name. When an adapted sub-page is constructed, allclasses used to style the content sections enclosed in the sub-page areexplicitly included inside the page's <style> tag. After the includingstep, the method can proceed to end (832).

FIG. 9 is a flowchart representing an exemplary method for transformingthe original webpage into a set of sub-pages. These sub-pages bear therelevant content of the original webpage in an order that is best suitedfor viewing in a mobile device; are formatted to fit the small screen ofa mobile device; and fit in the available memory of the mobile device.It will be readily appreciated by one of ordinary skill in the art thatthe illustrated procedure can be altered to delete steps or furtherinclude additional steps. After initial start step 900, the OS receives(902) adaptation parameters from a storage location. The adaptationparameters (e.g., the adaptation parameter provided in the chart above)provide information regarding the properties of a mobile device and itsuser agent and it helps the OS determine how to adapt the response datafor transmitting it to the mobile device.

A key definition on which the present method relies is a classificationof HTML elements, used to determine which action should be performed oneach corresponding node in the original DOM tree. These types ofclassifications break into three main groups: (1) grouping elements,such as <table> or <div> tags, that impose a specific layout orstructure to the content, but do not usually represent actual content;(2) ignored elements that do not provide any useful content; and (3)simple elements, such as font formatting tags, links, images, etc., thatrepresent content or non-layout inducing markup. An exemplaryclassification chart is provided below in Appendix A illustrating thespecific classifications for all HTML tags.

To further paginate, the OS identifies (904) sections of related contentin the original DOM tree to allow advanced content manipulation. Forexample, menus can be moved, or content can be reordered into a moreusable sequence, while preserving the logical and semantical grouping.The OS can perform identification of a content section based onstatistical pattern recognition techniques to minimize theclassification error. Content sections are used for arranging data thatshould belong together so that the adapted sub-pages maintain the lookand feel of the original webpage. To identify the content sections, theOS traverses the DOM tree structure. The OS then determines (906)whether to create a content section based on the geometric information(or box model[width, height]) of a node. The geometric information ofthe node determines whether a content section may be created from itssub-tree. To classify a node in the DOM tree as a content section, aseries of rectangles in the width×height plane (also called buckets) canbe used. The first condition for considering whether a DOM node shouldbe included in a content section is to determine whether the node fitsin one of these buckets, which are described in more detail below. If anode fits in one of the content section buckets, it is likely that itssub-tree will be in the same content section bucket. During thetraversal of each node of the original DOM tree, the following steps areperformed for finding content sections:

-   -   The depth first pre-order traversal of the DOM tree starts at        the root—an <html> tag.    -   The OS skips the current node and its sub-trees if the current        node is listed in the in the ignored element list.    -   The OS creates a content section for the current node if the        current node is a text node, resulting in the current node being        a leaf node, unless the text is filler text. Filler text can be        considered decorative and otherwise useless text, like a lone        pipe symbol or two colons.    -   The OS skips the current node if the current node is odd shaped        and is either an <image> or <iframe> tag. This classification        identifies images that are used for layout as spacers, shading,        ornamentation, or useless information that neither preserves the        original layout of the content data nor provides content. For        example, the OS can identify odd shaped elements when any of the        following are true:        -   (1) width in range (0,7) pixels;        -   (2) height in range (0,4) pixels;        -   (3) aspect ratio>5 and width <17 pixels;        -   (4) aspect ratio<0.04 and height <17 pixels;        -   (5) x coordinate <−width (no part of the object is rendered            on the screen); and        -   (6) y coordinate <−height (no part of the object is rendered            on the screen).    -   The OS can create a content section out of the current node if        tab box processing is enabled and the current node is classified        as a tabbed box (as described below).    -   The OS creates a content section if the current node has been        classified as a simple element.    -   The OS creates a content section if the current node is a        grouping element whose shape fits a content section bucket        classification (as described below) or is a hidden node, which        is determined through the CSS properties ‘visibility’ and        ‘display’.    -   The OS can recover from misidentifications of content sections        caused by the presence of nodes within the content sections that        have the “float” CSS property set. For detecting this situation,        the OS saves the geometry properties of the content section and        compares each node's geometry to the content section's geometry        during the small screen adaptation stage. A content section is        considered misidentified when the dimensions of one if the        node's children exceeds its own dimensions (meaning that either        the child's width or height are larger than the content        section's width or height).    -   If detecting a misidentification, the OS can discard the        originally misidentified content section and will invoke the        process for finding content sections on each of children of the        node originally misidentified as a content section.    -   If none of the above conditions are true for the current node,        the OS recursively invokes the aforementioned process on each of        the current node's children to determine whether any other        content sections should be created.

To classify nodes as content sections according to geometric properties,the OS can compare the content section buckets to the geometric datafrom a node. The content section buckets are empirically adjustedbeforehand to minimize the error in detecting content sections. Forexample, the following are exemplary content section buckets where thenormalized height or width is the height or width of the node, dividedby the total height or width of the page:

-   -   Small regions in width and height        -   (1) Width range [26, 165]        -   (2) Height range [1, 100000]        -   (3) Normalized Width range [0, 10]        -   (4) Normalized Height range [0.01, 0.324]    -   Wide, short regions (header and footer)        -   (1) Width range [165, 2000]        -   (2) Height range [1, 100000]        -   (3) Normalized Width range [0, 10]        -   (4) Normalized Height range [0.01, 0.324]    -   Small Boxes        -   (1) Width range [26, 2000]        -   (2) Height range [10, 150]        -   (3) Normalized Width range [0, 10]        -   (4) Normalized Height range [0, 0.01]    -   Columns        -   (1) Width range [26, 165]        -   (2) Height range [1, 100000]        -   (3) Normalized Width range [0, 10]        -   (4) Normalized Height range [0.324, 2]    -   Large Boxes        -   (1) Width range [165, 331]        -   (2) Height range [1, 100000]        -   (3) Normalized Width range [0, 10]        -   (4) Normalized Height range [0.324, 0.541]            While these exemplary content section buckets are            illustrated, one of ordinary skill in the art would            appreciate that any variations of this model can similarly            be derived for different cases.

Tab boxes are complex HTML constructs that fully exploit JavaScript HTMLvisibility control. For example, cnn.com provides a tab box having twotabs: a Top Stories tab and a Most Popular tab. When a user clicks oneither tab, the user gets the most recent stories corresponding to thatparticular tab for that particular time. Because of the tab box'scomplex structure, if configured to do so, the OS can recognize the tabbox constructs and can provide special adaptation to preserve the tabbox structures, which applies only to target devices that supportJavaScript.

To recognize tab boxes, the OS first examines a parent node's one ormore child nodes for a tab box structure having some visible and hiddenchildren nodes. At least one of each should be present for the node tobe considered a tab box. Next, the OS discards child elements that arenot likely to represent “tabs”. In some embodiments, the OS assumes thatall tabs in the tab box should have a similar DOM structure such as, thenumber of children of each tab being the same. For elements with farmore or less children than the tabs of a tab box, the OS assumes thatthese elements do not represent tabs and discards these elements fromthe decision. Finally, after considering only elements determined to betabs, the OS can compute the ratio of visible tabs to total tabs. If theratio is low (allowing for error in tab detection), the OS determinesthat the node, whose child elements are the tabs in question, is a tabbox. If a tab box is identified during the process of finding contentsections, a new content section is created out of it.

After identifying the content sections, the OS begins to process thesecontent sections by adapting the resulting DOM tree fragments fordisplayable at the mobile device. First, the OS transforms (906) theoriginal DOM tree structure for small screen rendering into an adaptedDOM tree structure (small screen adaptation). The transformation caninvolve two main ways: (1) flattening content that is too wide for themobile device's screen when rendered, and (2) preserving the layout forcontent that fits on the screen when rendered (e.g., the tab boxidentification described above, etc.).

Flattening involves fitting content that is too wide to be displayed ona mobile device's screen when rendered, and can be performed on allidentified content sections. The flattening process can includedeconstructing a portion of HTML that renders an area too wide for thetarget handset into smaller pieces. The OS can flatten the sub-tree byremoving layout imposing HTML tags until: the content itself is reached(e.g., simple elements), the current node fits in the target screen, thecurrent node is identified as a tab box, etc. The flattening processcopies useful, formatted content out of the original DOM tree into a newDOM tree for each content section. Other processing, such astranscoding, JavaScript Processing, Style Extraction, etc., can beexecuted simultaneously while visiting each node in the content section.The following provides an exemplary flattening scheme:

-   -   The OS copies the current node to the new document tree if the        current node is a text node, and it is not empty or filler text.    -   The OS skips the current node and its sub-tree if the current        node is odd-shaped and includes either an <image> or <iframe>        tag.    -   The OS skips the current node if the current node is on the list        of ignored elements.    -   The OS skips the current node if the mobile device's markup        language is XHTML/MP and the transcoder module indicates to skip        the node.    -   The OS skips the current node if the current node is a <span>        tag and its CSS visibility property is set to hidden.    -   If the current node is visible (CSS “display” property is set to        ‘block’ and its CSS visibility property is not set to ‘hidden’,        and coordinates are greater than zero) the OS checks the current        node's geometry against the geometry of its parent to determine        if the height or width of the current node is larger than its        parent. If this occurs, the currently processed content section        is most likely misidentified because of misleading geometry        resulting from the CSS float property. The flattening process        can then be aborted, and the process of finding content sections        resumes as previously explained. This step relates to the        process for checking cases of content section misidentification.    -   The OS directly copies the current node's JavaScript information        and all relevant style information if the current node is a tab        box. This preserves the complete look and functionality of the        tab box as it would appear on the original page.    -   The OS copies the current node's layout configuration to the new        DOM tree structure (unless the configuration disallows this in        the case where the target device does not support tables) if the        current node is a <td>, <table>, or <div> and its geometry is        between 0 and the screen width (non-inclusive).    -   The OS copies the current node to the new document tree and        flattens the node's children if the current node is on the list        of simple elements.    -   The OS gives special consideration to the current node to ensure        its width has been set correctly if the current node is an        <input> or <select> tag.    -   The OS further processes the current node if the node is an HTML        element and the mobile device's markup language is XHTML/MP. The        OS can coerce the node to comply with XHTML/MP by adjusting the        tag type or attribute list accordingly. For example the        transcoder would replace a <center> tag with <div        align=‘center’> tag.    -   The OS removes unneeded attributes, such as STYLE, VALIGN, ABBR,        ABINDEX attributes.    -   The OS processes an image associated with the current node for        determining the resizing information and for encoding the ‘src”        attribute accordingly (if the current node is an <image> or an        <input> of type image).    -   The OS discards the current node and its sub-tree if the node is        a form element without a submit button and the mobile device        does not support JavaScript.    -   The OS further processes the current node and its sub-tree if        the node is a form element with a submit button and the mobile        device supports JavaScript.    -   The OS further flattens each of the current node's children if        the node is a form element with a submit button and the mobile        device supports JavaScript.

The OS further transforms the new DOM sub-tree by inserting breaks intoan HTML tag. The HTML tag's CSS display property dictates whether abrowser should insert a break before and after the tag when the mobiledevice's browser renders the HTML. In some embodiments, some CSS displayproperty values, in conjunction with being applied to grouping tags,require breaks to be inserted before and after the grouping tags' nodesin the content section's DOM tree to best preserve the original layout.For example, a paragraph of text containing a link should not contain abreak before or after the link because the link text should appearinline with the rest of the text. In some embodiments, the CSS displayproperty values that can cause a break to be inserted are listed asfollows:

-   -   Block    -   Table    -   List-item    -   Table-row    -   Table-Cell    -   Table-column-group    -   Table-row-group

The OS further transforms the new DOM sub-tree by processing the formsfound in the original DOM tree structure. The flattening processgenerates a sequence of simple HTML elements in document order. Often informs, laying out HTML elements in document order can cause somedifficulty matching up the text used to describe a form element, a<select> or <input> tag, and the form element itself. Copying elementsin document order may result in text, text, text, followed by formelement, form element, form element. This will confuse the user aboutwhich text label corresponds to which form element. For example, FIG.11A illustrates how a mobile device may render form data. For example,form labels FROM 1100, TO 1102, DEPARTURE DATE 1104, and RETURN DATE1106 do not match up with their corresponding form elements 1108, 1110,1112, and 1114, respectively. The purpose of form processing is to matchup the form labels with their corresponding form elements, as shown inFIG. 11B.

FIG. 10 is a flowchart representing an exemplary method for performingform processing. It will be readily appreciated by one of ordinary skillin the art that the illustrated procedure can be altered to delete stepsor further include additional steps. After initial start step 1000, theOS locates (1002) a <form> tag during the flattening process therebytriggering the form processing on the <form> tag's sub-tree.

After locating a <form> tag, the OS can search (1004) within the <form>tag for a <tr> or <div> tag with at least two form elements nestedunderneath it. When the OS locates that instance of a <tr> or <div> tag,the OS saves (1006) the position of the previous occurrence of the <tr>or <div> tag and flattens everything up to that position. At this point,the OS has isolated two nodes whereby the first node's sub-tree mightcontain text nodes that correspond with the second nodes sub-tree's formelements.

The OS can then attempt to rearrange the sub-trees of the two nodes sothat the form labels can be associated with their corresponding formelements. Before the rearranging occurs, the OS scans (1008) the firstnode's children to determine (1010) whether the form label exists in thefirst node that describes the form elements in the second node. If theOS finds another form element at the same level as the form label in thefirst node's sub-tree or finds nothing, the re-arranging will not occurand the OS will continue flattening (1014) the node of the DOM treestructure. The method will proceed to connector 1016 and then end(1018).

On the other hand, if the OS locates a <label> tag or finds textcontained inside of a cell of the <tr> or <div> tag, the OS canrearrange (1012) the nodes so that the form labels will correspond withtheir form elements. This re-arrangement occurs by the OS taking thesub-tree of each of the first node's children, having the form label,that qualify to be rearranged and appending these children to afakeroot. This fakeroot's children are then interlaced within the secondnode's children that contain form elements so that the form labels arecorrectly associated with the form elements as shown in FIG. 11B. Afterthe re-arranging, the method will proceed to connector 1016 and then end(1018).

Referring back to transformation step (906) in FIG. 9, in someembodiments, flattening can be unnecessary because a webpage designerhas laid out the into an area that is small enough for the mobiledevice's screen size. In this case, a layout preservation functioncopies the sub-tree representing the small section, including thegrouping and layout tags, to preserve the original designer's layout.

During DOM traversal, for any <div>, <td>, or <table> tag whosedimensions fit within the screen width, the layout is preserved and theOS copies the sub-tree corresponding to these tags as-is. In someembodiments, some conditions may invalidate a node's sub-tree; hence,allowing the flattening to continue on that originally discovered node.Also, the layout preservation function performs much of the samefunctionality checks that are provided in the flattening process becauseboth functions are trying to filter the tags before adding them to thecontent section's adapted DOM tree. For example, the layout preservationfunction can perform the following checks and error conditions:

-   -   If necessary, the OS performs transcoding on a node by node        basis.    -   The OS can include <Input> or <Select> tags that are not        included inside of forms if JavaScript is supported on the        device.    -   The OS can ensure that a form has some way of submitting itself        to a mobile device that does not support JavaScript; otherwise,        the layout preservation function does not preserve the layout of        this sub-tree.    -   The OS ignores odd shaped images and iframes.    -   The OS ignores hidden <span> tags.    -   The OS can invalidate a float element if the float element is        found because its dimensions are probably incorrect.    -   The OS replaces a <td> tag with a <div> tag if a root node        includes a <td> tag because the flattening process has removed        the parent table tag and the layout preservation function the        adapted DOM tree structure cannot have floating <td> tag in an        output HTM.    -   Some browsers (specifically NetFront) may have problems        rendering <div> tags with small dimensions (e.g., less than 20        pixels). These problems occur when small <td> tags are replaced        with <div> tags (i.e. www.cnn.com). To remedy this, the OS can        insert a <br> tag before appending the new <div> tag.    -   The OS can modify and include filler text. For example, spacer        text, a form of filler test, can be used by a mobile device's        browser for layout information. The OS can replace the filler        text with a single space prior to removing all filler text.    -   The OS can promote Lowsrc attributes values to src attribute        values.    -   The OS can set a flag “preFormat” (used for style) for each node        added to the adapted DOM tree. If a node is created using the        layout preservation function (preFormat flag set), the node's        class and <id> tag are left intact so that JavaScripts, that        reference them, may still function properly.

Regarding the processing of a tab box, when locating a tab box, the OScopies the entire DOM sub-tree and all of its CSS style propertiesexplicitly set in the sub-tree and applies them to the adapted DOM treestructure to achieve an exact replica of the original layout.

While transforming the original DOM tree structure into a new, smallscreen adapted DOM tree structures, the OS performs (908) the JavaScriptprocessing in FIG. 7 and the content styling performed in FIG. 8,collecting all JavaScript and style data required to assemble the finalHTML page(s). The OS can then serialize (910) the adapted tree structureby transforming it into HTML text. As noted above, a content section mayexceed the limitations of the target mobile device (i.e. memory, numberof links, etc). Therefore, if it is determined within serialization thatthe resulting page will break a device limit, the OS can break thecontent section into multiple presentation units. In a truly flattenedtree, it can be very difficult for the OS to determine where to insert apresentation unit division between two simple elements. Instead of trueflattening, the OS can copy a sub-tree representing a content sectiondirectly from the original DOM sub-tree to the adapted DOM treestructure to preserve the original sub-tree's structure, and can markall grouping elements as transparent nodes. Transparent nodes assist inretaining the original grouping of simple elements and assist theserialization process. Serialization is performed bottom-up, and failswhen any of the device limits are exceeded (determined by counters forbytes, # of images, etc). When the serialize function fails on the rootof the content section, the OS then attempts to recursively create apresentation unit for the sub-tree that begins at each of the root'schildren. As each presentation unit is created, the OS caches thesepresentation units in the nodes themselves so future invocations of theserialize function will not perform traversals deeper into the tree.When the sub-tree of a simple element exceeds the device limits (i.e. alarge paragraph of plain text), the serialization function breaks thesimple element into multiple presentation units and re-serializes them.

Once the list of content sections have been created and each contentsection contains a list of one or more presentation unit (each beingsmaller than the maximum page size), the OS can construct the actualsub-pages. To begin constructing the sub-pages, the OS can construct(912) one or more adapted sub-pages. The construct function populatesthe final page list with newly created presentation units by traversingall content section's presentation units one at a time. By loopingthrough all presentation units of all content sections, the constructfunction determines whether each presentation unit should go on thecurrent sub-page or whether a new sub-page should be started so that thegenerated sub-pages comply with the mobile device's limitations. Forexample, the determination can be based on the followingcharacteristics:

-   -   Adding the presentation unit to the current sub-page if the        sub-page's size is 0.    -   Starting a new page if adding to the current sub-page would        exceed any limit of the device.    -   Adding the presentation unit to the current sub-page if the        page's byte count is still under the minimum “preferred” byte        size (prevents tiny pages except at the end).    -   Adding the presentation unit to the current sub-page if it is        the last presentation unit (sometimes prevents small final        pages).    -   Optimizing the current page's byte size towards the average byte        size (bytes left/preferred pages left) by starting a new page if        the current one already exceeds the average, or if adding the        presentation units to this page would exceed the average more        than the current deficiency of presentation units.    -   Adding the presentation unit to the current sub-page if a        preferred number of pages have already been exceeded.    -   Adding the presentation unit to the current sub-page if none of        the above conditions apply.

Because the content styling has already been applied in the presentationunit's outer-most <div> tag, the build pages process can add the HTMLgenerated by the serialization function to put one or more sub-pagestogether. A presentation unit includes information concerning itsrespective content styling classes and JavaScript. When multiplepresentation units are combined into a sub-page, the respective contentstyling classes and JavaScript are also combined into that sub-page. Theconstruct function also extracts each menu content section out of themain page sequence and creates a new sub-page sequence for theseextracted sections.

After constructing the sub-pages, the OS identifies (914) menu contentsections and moves these menu content sections out of the main browsingpath to a separate browsing path. This prevents large sections of linksfrom taking up the first few pages in a sub-page sequence. For example,espn.go.com provides a menu that is small in size for the browser butextremely long when displayed in single-column format on a device. Theconstruction function can insert a menu link into the DOM tree where themenu content section was extracted from. In some embodiments, theconstruction function can replace a section having hundreds of linkswith a single link to the new page list; thereby allowing thepresentation unit to retain all of its original content and allowing theuser to skip browsing through excessive pages of menus to get to themain content.

To identify these menu content sections, the OS calculates a menu scoreon all content sections on the list for determining whether a contentsection is a menu content section. A score is produced from multiplestatistics collected about the content section during flattening andserialization and if the score exceeds a threshold, the OS classifiesthis content section as a menu and moves this content section to a newsub-page. For example, the menu score can be based on the following:

-   -   The menu score can be proportional to the link density, which is        the number of links divided by the area of the content section.    -   The menu score can be proportional to the placement of the        content section relating to the document order. Sections near        the beginning of the document are classified as menus more        aggressively because menus at the beginning of the adapted        sub-page can hinder the user's experience.    -   The menu score can be increased if determined that the URL of        the original document does not look like the URL of a homepage.        This makes menu classification more aggressive on pages where        navigational links are less important that content.    -   The menu score can be proportional to the number of links in the        content section because having more links indicates a likelihood        that the content section is a menu.    -   The menu score can be increased if the links within the content        section refer to pages whose URLs do not look like the URL of a        homepage.    -   The menu score can be decreased if the content section includes        more text than link bytes. Long text links are less likely to be        a menu because they are more likely related to the page's        content.        If the menu score of a content section exceeds a predetermined        threshold, the OS shall classify the content section as a menu        content section and move this section back to a later sub-page.

After distinguishing between the menu and non-menu content sections, theOS encloses (916) the sub-pages with a header and footer whenappropriate. The header and/or footer allow a user to navigate throughthe sub-pages within a sub-page sequence. The enclose function involvesadding the appropriate header and doctype; writing the <head> tag (whichincludes CSS classes and scripts that are used in the page) into thesub-page's HTML buffer; and creating a navigational header and footerfor the user. In some embodiments, the adapted main sub-page and/or thesubsequent sub-pages may not include a header. Further, the headerand/or footer can include, among other things, links to nearbysub-pages, links to sub-pages that are multiples of 10 away from thepresent sub-page, and links to the first and last sub-page. For example,the link can be a page number, an image, or a name of the sub-page. Insome embodiments, links to the previous and next sub-page contain softkey attributes. Further, in some embodiments, the footer may include ananchor with a soft key. The footer may also include a static descriptionof any enabled soft keys.

For a menu sub-page, the header and footer can be exactly the same. Ifthe menu fits in a single page, the header and footer may only have alink to return to the place the menu was extracted from in the mainsequence; otherwise, Prey and Next links can be included when there is aprevious or next menu sub-page. After the sub-pages have been enclosed,the method can end (918).

In some embodiments, to improve the usability of the resulting pages onsmall screen devices and minimize the byte count, it may be desirable toresize large images. The pagination function can prepare images forresizing by gathering geometric data and calculating the necessaryresizing factor. Because the pagination engine already has informationabout the size of the target device's screen and has access to thegeometric information of an image when it is rendered on the screen, thepagination engine is well suited to perform this calculation. Whenreceiving the original image URL, the OS can calculate an appropriateimage size and resize it accordingly.

In some embodiments, before content adaptation is performed, there aresome HTML responses (e.g., HTML redirects, etc.) that should not beadapted. Some websites send back HTML responses that redirect a user toa different website rather than using the HTTP for redirects. Thesewebsites often include this redirect information in the originaldocument's meta tag, but this information could be stripped out by thepagination engine thereby creating a blank page that would not redirectto the intended page. To avoid this, a mechanism could be provided intothe content adaptation engine to scan the document's meta tag for“HTTP-EQUIV=‘Refresh’ content=‘ “’with the “content=” having a very lowtimeout and a URL. If this is found, the page can be transcoded andreturned. Now, the mobile device can receive an HTML page capable ofredirecting to the intended page.

The methods disclosed herein may be implemented as a computer programproduct, i.e., a computer program tangibly embodied in an informationcarrier, e.g., in a machine readable storage device or in a propagatedsignal, for execution by, or to control the operation of, dataprocessing apparatus, e.g., a programmable processor, a computer, ormultiple computers. A computer program can be written in any form ofprogramming language, including compiled or interpreted languages, andit can be deployed in any form, including as a stand alone program or asa module, component, subroutine, or other unit suitable for use in acomputing environment. A computer program can be deployed to be executedon one computer or on multiple computers at one site or distributedacross multiple sites and interconnected by a communication network.

In the preceding specification, the invention has been described withreference to specific exemplary embodiments. It will however, be evidentthat various modifications and changes may be made without departingfrom the broader spirit and scope of the invention as set forth in theclaims that follow. The specification and drawings are accordingly to beregarded as illustrative rather than restrictive sense. Otherembodiments of the invention may be apparent to those skilled in the artfrom consideration of the specification and practice of the inventiondisclosed herein.

1. A server comprising: a response monitor configured to receiveresponse data from a content server, wherein the response data includesa webpage and corresponds to a request for the webpage from a mobiledevice; and an adaptor configured to adapt the webpage based on theproperties of the mobile device, wherein the adapted webpage is providedto the mobile device for downloading, wherein the adaptor determineswhether the webpage is a redirect page and adapts the webpageaccordingly so that the downloaded adapted webpage, provided at themobile device, can redirect a user to a different webpage.
 2. The serverof claim 1, wherein the adaptor determines whether the webpage is aredirect page by determining whether the webpage includes a meta tagindicating that an http-equiv parameter comprises a refresh value andthat a content parameter includes a timeout value and a URL value.
 3. Amethod comprising: receiving response data from a content server,wherein the response data includes a webpage and corresponds to arequest for the webpage from a mobile device; determining whether thewebpage is a redirect page; upon the determination that the webpage is aredirect page, adapting the webpage based on the properties of themobile device so that the adapted webpage, when provided to the mobiledevice, can redirect a user to a different webpage; and providing theadapted webpage to the mobile device.
 4. The method of claim 3, whereindetermining whether the webpage is a redirect page includes determiningwhether the webpage includes a meta tag indicating that an http-equivparameter comprises a refresh value and that a content parameterincludes a timeout value and a URL value.
 5. A non-transitory computerreadable medium storing instructions that, when executed by a computer,cause the computer to perform a method of webpage adaptation, the methodcomprising: receiving response data from a content server, wherein theresponse data includes a webpage and corresponds to a request for thewebpage from a mobile device; determining whether the webpage is aredirect page; upon the determination that the webpage is a redirectpage, adapting the webpage based on the properties of the mobile deviceso that the adapted webpage, when provided to the mobile device, canredirect a user to a different webpage; and providing the adaptedwebpage to the mobile device.
 6. The computer readable medium of claim5, wherein determining whether the webpage is a redirect page includesdetermining whether the webpage includes a meta tag indicating that anhttp-equiv parameter comprises a refresh value and that a contentparameter includes a timeout value and a URL value.